%        File: memoria.tex
%     Created: sáb jun 28 01:00  2008 C
% Last Change: sáb jun 28 01:00  2008 C
%
\documentclass[a4paper,spanish,12pt]{book}
\title{BLAS: Base Layer for Application Services}
\author{Eduardo Orive Vinuesa}
\usepackage{babel}
\usepackage{times}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[left=2.5cm, right=2.5cm]{geometry}
\usepackage{a4}
\usepackage{makeidx}
\usepackage{graphicx}
\usepackage{float}
\usepackage{url}
\usepackage{setspace}
\onehalfspacing
\usepackage{fancyheadings}
\usepackage{wrapfig}
\usepackage{verbatim}
\usepackage{hyperref}
\usepackage{appendix}
\onehalfspacing

\begin{document}

%\maketitle

\include{portada}
\cleardoublepage

\include{copyright}
\pagenumbering{Roman}

% Dedication

\cleardoublepage

\vspace*{6cm}
	\begin{flushright}
		\begin{em}
			A mi familia, por su apoyo.
       		\end{em}
	\end{flushright}
\cleardoublepage

\chapter*{Agradecimientos}

Quiero agradecer en primer lugar a Agustín la confianza que ha depositado en mi y en mi proyecto, así como a Gregorio que ha accedido a ser mi tutor. Los dos han dedicado cantidades ingentes de paciencia para que este proyecto tuviera el objetivo que había planteado y que verdaderamente me ilusionaba.

Tambi\'en mis compañeros han demostrado gran inter\'es en el proyecto y no han dejado de proporcionarme ánimo y consejos, y en especial a Alberto, Jesus e Iván.

A mis padres y a mi hermano que siempre han mostrado su disposición para ayudarme en lo que pudieran, incluyendo la tortuosa búsqueda de erratas en el texto.
\cleardoublepage

%cuerpo del documento
\chapter*{Resumen}
BLAS es una plataforma pensada para orientar los esfuerzos dedicados a programar un servicio de Internet. Originalmente pensado para protocolos de tipo de texto sobre TCP/IP, se ha extendido su funcionalidad a UDP/IP y en un futuro se proveerá un soporte más fiable para protocolos binarios.

Con el objetivo de mejorar el proceso de diseño e implementación esta plataforma propone organizar el proceso de atención de las peticiones en una serie discreta de estados, lo más simples posible, estos estados se materializan en m\'etodos con identificadores unívocos que van dirigiendo la ejecución de uno a otro. Este modo de diseño estructura y facilita de forma considerable el trabajo sobre protocolos con un formato determinado.

El desarrollo de servicios con este sistema provee de una estructura y permite acelerar el proceso de obtención de un prototipo estable.

La elección de Python como lenguaje ha permitido una gran flexibilidad en la programación y sobretodo claridad en el código resultante. Precisamente mantener la claridad en la implementación es una de las principales premisas a la hora de orientar la programación de los servicios.

Se ha optado por la licencia GPL para proteger el proyecto y garantizar su disponibilidad futura, en especial a la comunidad de estudiantes y facilitar la participación a aquellos interesados en la platafoma y en el software libre.

\cleardoublepage


\pagestyle{plain}
\newpage
\tableofcontents
\newpage
\listoffigures
\cleardoublepage

\pagenumbering{arabic}

\pagestyle{fancyplain}


\chapter{Introducción}
Actualmente casi la totalidad de las instalaciones inform\'aticas son redes, y una mayoria de estas est\'an conectadas a Internet e incluso la propia Internet forma parte de estas.
\begin{figure}[h] %{r}{0.35\textwidth}
	\begin{center}
	\includegraphics[width=0.65\textwidth]{img/SistemasDistribuidos.eps}	
	\end{center}
	\caption{Ejemplo de un Sistema Distribuido}
	\label{fig:SistemasDistribuidos}
\end{figure}
\section{Historia de los servicios informáticos}
Despu\'es del desarrollo de la primera generación de computadoras el número de estas empezo a aumentar, aunque su disponibilidad estaba normalmente limitada a una unidad por cada entidad (instituciones educativas e instalaciones militares). Estas máquinas requerían de un entorno ambiental muy concreto y el acceso a las instalaciones donde se albergaban estaba severamente restringido. Por estas mismas limitaciones y para maximizar la disponibilidad se ideó un sistema limitado de terminales remotas, los teletipos, cuya función era comunicar con el ordenador central pudiendo utilizar enlaces dedicados o conmutados (líneas telefónicas), permitir la inserción de programas y recuperar el resultado una vez el sistema hubiera finalizado. Estos sistemas de comunicación y control remotos merecen la consideración de servicios informáticos.

Con el tiempo la versatilidad de los sistemas fue ampliandose, los ordenadores dejaron de emplearse como meras ejecutoras de algoritmos y empezaron a ofrecer distintos tipos de servicios:
\begin{enumerate}
	\item Boletines de noticias
	\item Transferencias de ficheros
	\item Correo electronico
\end{enumerate}
Es precisamente en esta \'epoca cuando empiezan implantarse sistemas de comunicación por conmutación convencionales y los servicios empiezan a ser utilizador desde estos nuevos medios de enlace. La oferta de servicios deja de estar limitada a las grandes entidades y empiezan a surgir ``BBSes'' (Bulletin Board System) albergadas en ordenadores privados. Durante más de 25 años han sido un medio de comunicación y entretenimiento, en opinión de muchos, siguen siendo los mejores ambientes comunitarios. 

La capacidad monousuario de los sistemas de la \'epoca presentó la necesidad de empezar a dejar de utilizar enlaces de líneas conmutadas para añadir un nuevo nivel de paquetes conmutados para eliminar esta limitación.

Con el tiempo y con el inexorable cumplimiento de la ley de Moore, los sistemas fueron ampliando geom\'etricamente su capacidad, tambi\'en lo hacía su disponibilidad en el mercado haci\'endose cada vez asequibles para el público en general, acompañado por una reducción drástica del volumen y consumo energ\'etico.  

La popularización de Internet llevó a que practicamente cualquier ordenador dom\'estico estuviera dotado de algún dispositivo de comunicación metropolitana y una pila IP, permitiendo así acceder a los servicios ofrecidos en Internet a trav\'es del respetivo ISP. 

En poco tiempo dispositivos portátiles imitaban la tendencia junto a otros microdispositivos. Es muy común ver que aparatos convencionales, desde electrodomesticos a vehículos lleven incorporados sistemas de comunicación que automáticamente son capaces de desempeñar tareas como emitir a la central la posición del vehículo y todo tipo de medidas cuantificables sobre su estado. 

\section{Motivación}

En los último años cursando Ingeniería Informática y en proyectos profesionales se ha presentado en númerosas ocasiones la necesidad de escribir servicios orientados a Internet. La necesidad de encontrar un sistema estructurado y ágil para la elaboración de prototipos es lo que ha inspirado la creación de esta plataforma.

Es en este entorno donde se desarrollan las arquitecturas de la mayor\'ia de los sistemas. Distribuidas, y en una gran proporci\'on siguiendo el modelo Cliente-Servidor, casi todas las nuevas aplicaciones o sistemas basan gran parte de su funcionalidad en la conectividad mediante redes. 

Sin embargo realizar aunque sea un prototipo operativo de un servicio de red requiere de una importante inversión en tiempo y no se obtienen resultados tangibles hasta que se ha implementado una buena parte del código.

Tambi\'en es muy com\'un ver que muchos prototipos sean descartados (total o parcialmente) y deban re-implementarse ya que, aunque su rendimiento sea aceptable, la seguridad que ofrecen no lo es, con lo que el proceso de crear el servicio duplica su coste cuando el sistema llega a la etapa de producci\'on.

No obstante la escritura de un servicio de Red puede reducirse considerablemente si se implementan tan solo las características particulares de su protocolo. Basicamente cualquier protocolo puede entenderse como un autómata m\'as o menos complejo, siguiendo este modo de diseño puede simplificarse de manera considerable el trabajo tanto del programador como del analista.

La intención principal de esta plataforma es evitar la reimplementación innecesaria de funcionalidades que son comunes a todo tipo de servicio de red interactivo, además de proponer una metodología concreta en la implementación.
\section{Disponibilidad del proyecto}
Este proyecto se ha traspasado desde una de sus más primitivas versiónes al repositorio que Google dispone para desarrolladores. La elección de \url{http://code.google.com/} como repositorio se ha debido sobre todo al elenco de herramientas y servicios que Google está dedicando a los desarrolladores de software y sobre todo a los proyectos de programación colaborativos.

Todo el código y la documentación referente a este proyecto podrá encontrarse en \url{http://code.google.com/p/blas/}. La participación de terceros quedará abierta en cuanto se evalue el proyecto, en mi opinión ese será el verdadero comienzo del desarrollo de la plataforma, cuando se pruebe su uso y las aportaciones de otros desarrolladores amplien sus funcionalidades.

La documentación puede encontrarse también en formato LaTex, un procesador de textos muy adecuado para documentación cientifica y técnica \url{http://www.latex-project.org/}. Además los diagramas que ilustran este documentos se encuentran disponibles en su formato nativo, editable por Dia \url{http://www.gnome.org/projects/dia/}.
\section{Licencias}
Este proyecto dispone de dos licencias: una para el propio software que garantice a futuros la disponibilidad de este para toda la comunidad de software libre, otra para este documento, de tal forma que su contenido pueda aprovecharse en otros esfuerzos de documentación colaborativa como \url{http://es.wikipedia.org}.

Ambas licencias pueden encontrarse en sus respectivos ap\'endices.
\chapter{Objetivos}

Esta plataforma se ha ideado para facilitar el diseño y la implementación a los colectivos que por diversos motivos se ven ante la necesidad de programar un servicio de red en poco tiempo. 

Existen multitud de funcionalidades ligadas a los programas que ofrecen servicios sobre TCP y UDP que inevitablemente consumen mucho tiempo para su implementación y que normalmente los programadores se encuentran realizando funciones de implementación muy similares de un proyecto a otro pero sin permitir una reutilización eficiente del código.

Básicamente estas tareas se reducen a:
\begin{enumerate}
	\item Entrada controlada de datos.
	\item Registro (o registros) de actividad y error.
	\item Lectura de los archivos de configuraci\'on.
	\item Parseado de los parámetros de arraque.
\end{enumerate}

El objetivo principal de esta librería es facilitar las tareas de diseño e implementación de este tipo de software, acelerando la aparición de prototipos que permitan iniciar lo antes posible la depuración tanto del servicio como de los clientes.

Es posible que existan dudas sobre si hoy día la comunidad de desarrolladores tiene la necesidad de la realizacion de este tipo de software. En la actualidad se pueden encontrar cientos de implementaciónes de protocolos sobre multitud de tecnologías diferentes, pero todavía siguen apareciendo proyectos que requieren de la implementación de servicios de protocolos antiguos o nuevos.

\section{Docencia}
Existen númerosos proyectos acad\'emicos que requieren la implementaci\'on de:
\begin{enumerate}
	\item Protocolos nuevos.
	\item Protocolos ya existentes.
	\item Modificaciones sobre protocolos antiguos. 
\end{enumerate}

y que pueden ver facilitada su realización utilizando esta plataforma.

\section{Microdispositivos}
La mayor\'ia de los dispositivos dotados de un sistema operativo m\'inimo disponen de una modesta pila IP ya que, prácticamente todos estos dispositivos, se dise\~{n}an incluyendo algún tipo de hardware de interconexi\'on mediante enlaces de radio o cableado. Sin embargo por razones de coste económico y rendimiento energ\'etico se ven afectados por una leve capacidad de memoria y/o potencia de c\'alculo que hacen que la opción de comunicarlos mediante un servicio convencional (HTTP y REST por ejemplo) resulte muy engorrosa (y caro) en su programaci\'on, e incluso a veces impracticable.

Es por este motivo que se suelen dise\~{n}ar protocolos normalmente muy escuetos, especificamente adaptados a la funcionalidad del dispositivo y a sus limitaciones de proceso.

\section{Seguridad Inform\'atica}
En un entorno en que los ataques mediante gusanos son casi rutinarios, se emplea mucho tiempo y esfuerzo en crear servicios que se comporten como los originales que emplee el gusano para penetrar en el sistema y as\'i poder estudiar qué acciones realiza una vez dentro.

La capacidad de programar servicios simulados ágilmente puede ser un complemento perfecto a otras herramientas de estudio de la seguridad como son las 'Honey-Nets', dotando a las m\'aquinas virtuales de un comportamiento mucho m\'as flexible.



\chapter{Estado del arte}

\section{Lenguaje: Python}
\subsection{Elecci\'on del Lenguaje} 
Se ha elegido Python como lenguaje de programaci\'on para esta plataforma por las siguientes razones:
\begin{description}
	\item[Velocidad de aprendizaje] cualquier persona que conozca un lenguaje orientado a objetos puede aprenderlo en muy poco tiempo.
	\item[Reflexividad e introspección] Las clases en Python tienen conocimiento de sus propios m\'etodos y atributos.
	\item[Interpretado] Al ejecutarse bajo un interprete no har\'an falta compilar distintos ejecutables seg\'un la plataforma.
\end{description}

Con el empleo de Python se puede conseguir con pocas líneas la implementaci\'on de un protocolo completo. Al tratarse de un lenguaje en que la identaci\'on es obligatoria y la sintaxis muy clara, normalmente de produce un código fuente bien estructurado y que resulta fácil de leer incluso para quienes apenas conozcan Python.

\subsection{Python: historia y características}

Python fue creado como sucesor del lenguaje ABC por Guido van Rossum en 1990 cuando trabajaba en el Stichting Mathematisch Centrum (CWI). En 1995 Guido continuó su trabajo en Python en el CNRI donde creó muchas versiónes del lenguaje. En mayo del 2000 Guido y el equipo de desarrollo de Python se trasladan a BeOpen.com y se forma el BeOpen PythonLabs. En octubre de este mismo año, PythonLabs se va a Digital Creations (actualmente Zope Corporation). En 2001, se crea la Python Software Foundation (PSF), una organización sin ánimo de lucro creada específicamente para proteger la libertad de Python como lenguaje de código abierto.

El nombre del lenguaje proviene de la afición de su creador original, Guido van Rossum, por los geniales humoristas británicos Monty Python.

Python ha sido usado para crear programas tan famosos como el gestor de listas de correo Mailman o los gestores de contenido Zope y Plone.

Python se puede encontrarse en varias encarnaciones. En el sitio web de la Python Software Foundation, aunque el interprete original de Python está implementado en C. existen otras:
\begin{enumerate}
	\item Basada en Java existe una implementación denominada Jython puede utilizarse para trabajar con código Java nativamente. 
	\item Iron Python, una versión en C\# existe para hacer uso de las plataformas Mono y .Net y que los programadores de estas puedan beneficiarse de su potencia y flexibilidad. 
\end{enumerate}
En cada una de estas encarnaciones Python se ha escrito en un lenguaje y funciona nativamente en este aunque puede también interactuar perfectamente con otros lenguajes a trav\'es de sus correspondientes módulos.

Con propósitos de investigación y desarrollo existe tambi\'en una implementación de Python sobre Python. El proyecto PyPy fue iniciado en 2003 con la intención de permitir a los programadores en Python modificar el comportamiento del interprete. Además se trata de un proyecto de código abierto, desarrollado por una comunidad para su libre distribución y modificación. PyPy está patrocinado por la Unión Europea como un STReP (Specified Targeted Research Project), parte del plan de apoyo FP6.

\subsection{Evolución}

\subsubsection{Primera publicación}

En 1991 van Rossun publicó el código (con la versión 0.9.0) en alt.sources. Ya en este primer estado de desarrollo había clases con herencias, manejo de expeciones, funciones y los tipos de datos básicos de listas, diccionarios, cadenas y demás. Tambi\'en en esta publicación inicial había un módulo de sistema que fue tomado prestado de modula3; van Rossum define este modulo como ``una de las principales unidades de programación de Python''. El modelo de gestión de excepciones de Python tambi\'en imita al de Modula3 salvo que incluye la cláusula ``else''. En 1994 arranca comp.lang.Python, la primera lista de discusión de Python, marcando un hito en el crecimiento de la base de usuarios de Python.

\subsubsection{Versión 1.0}

Python llegó a la versión 1.0 en Enero de 1994. Las principales nuevas funcionalidades incluídas en esta publicación fueron las utilidades de programación funcional lambda, map, filter y reduce. Van Rossum expresó que ``Python ha conseguido lambda, reduce, filter y map por cortesía (en mi opinión) de algún hacker de Lisp que las echabada de menos y envió parches operativos''.

La última versión publicada cuando van Rossun estaba en el CWI fue Python 1.2. En 1995 van Rossum continuó su trabajo en la Corporación para Iniciativas de Desarrollo Nacional (CNRI) en Reston (Virginia) desde la que publicó varias versiónes.

Por la versión 1.4, Python había conseguido varias nuevas funciones. Es de destacar que entre estas están los parámetros por palabra clave de Modula3 (que son tambi\'en similares a los parámetros por palabra clave de Lisp) y el soporte integrado para números complejos. Tambi\'en incluye una forma básica de ocultamiento de datos por manipulación de nombre, aunque podía ser facilmente obviado.

Durante la estancia de var Rossum en el CNRI, lanzó la iniciativa Programación de Ordenadores para Todos (CP4E), que pretendía hacer la programación más accesible a mas gente, con un conocimiento básico en lenguajes de programación, de forma similar a los conocimientos básicos de literatura inglesa y matemáticas que se exigen a cualquier empleado. Python sirvió con un papel central en esto: debido a su enfoque en una sintaxis clara, ya podía considerarse un candidato adecuado para los objetivos del CP4E, estos ya apuntaban a su predecesor ABC. El proyecto fue fundado por DARPA. En 2007 este proyecto parece inactivo y aunque Python pretende ser de fácil aprendizaje y no demasiado arcano en su sintaxis y semántica, el llegar a ser comprensible para los no programadores no es una intencion activa.

\subsubsection{Versión 2.0}

Python 2.0 introdujo la comprensión de listas, una función prestada de los lenguajes de programación funcionales Lips y Haskell. La sintaxis de Python en su construccion es muy parecida a la de Haskell, dejando a un lado la preferencia de Haskell por los caracteres de puntuación y la preferencia de Python por las palabras clave alfabéticas. Python 2.0 tambi\'en introdujo un sistema de recolección de basura capaz de tratar referencias cíclicas.

Python 2.1 era bastante parecido a Python 1.6.1, al igual que Python 2.0. La licencia cambió su nombre a Python Software Foundation License. Todo el código, documentación y especificaciónes añadidas, desde la versión alpha de Python 2.1, es propiedad de la Python Software Foundation, una organización sin ánimo de lucro formada en 2001, modelada siguiendo el ejemplo de la Apache Software Foundation. La publicación incluyó un cambio en la especificación del lenguaje para soportar intervalos (scopes) anidados, al igual que otros lenguajes con intervalos estáticos. Esta función estaría desactivada por defecto y no fue necesaria hasta Python 2.2.

Una de las principales innovaciones en Python 2.2 fue la unificación de los tipos de Python (tipos escritos en C) y clases (tipos escritos en Python) en una única jerarquía. Esta unificación hizo al modelo de objetos de Python un modelo orientado pura y consistentemente a objetos. Tambi\'en se añadieron generadores inspiradores por el lenguaje Icon.

\subsubsection{Versión 2.6}

En el momento de desarrollar esta librería, Python 2.5 y Python 3.0 conviven en muchos proyectos; sin embargo y aunque se pueda ejecutar sobre 3.0, el poco tiempo que lleva la versión 3.0 en funcionamiento hace poco recomendable su utilización en sistemas que requieran de una cierta estabilidad o sean candidatos a producción.

\subsubsection{Disponibilidad}

En muchos sistemas operativos Python es un componente estándar, se incluye en la mayoría de las distribuciones de Linux, NetBSD, OpenBSD y con Mac OS X. Slackware, Red Hat Linux y Fedora utilizan el instalador Anaconda, escrito en Python. Gentoo Linux utiliza Python en su sistema de administración de paquetes Portage, y su herramienta por defecto Emerge. Pardus lo utiliza para administración y durante el arranque del sistema.

\subsubsection{Editores}

Python puede programarse con cualquier tipo de editor y siempre permitirá una lectura clara y una estructura adecuada del código. Sin embargo, son muchos los editores y entornos integrados de trabajo que incluyen funciones de ayuda en la programación:
\begin{enumerate}
	\item{Resaltado del código: Cualquier editor con unas funcionalidades de programación mínima incluirá resaltado de sintaxis.}
	\item{Predicción de escritura: Prácticamente cualquier editor incluirá indentación automática y probablemente predicción de palabras clave.}
	\item{Gestión de proyectos: Disponible sobre todo en IDEs y raramente en editores.}
	\item{Shell integrada: Disponible en algúnos de los editores y la mayoría de los IDEs.}
\end{enumerate}

Para conseguir una lista actualizada de editores compatibles con Python en todas las plataformas puede conseguirse en esta URL: 
http://wiki.Python.org/moin/PythonEditors


\section{Protocolos de red: IP}
Es difícil generalizar sobre protocolos ya que estos varían ampliamente en propósito y en complejidad. La mayoróa de los protocolos de red poseen algúna de las siguiente propiedades:

\begin{wrapfigure}{r}{0.35\textwidth}
	%{figure}[h]
	\includegraphics[width=0.25\textwidth]{img/NivelesOSIRed.eps}	
              \caption{Niveles OSI: protocolo de red}
  \label{fig:nivelesOSIRed}
\end{wrapfigure}


\begin{enumerate}
\item Detección de la capa subyacente de enlace de red, o la existencia de otro punto de entrada o nodo.
\item Saludo y reconocimiento (Handshaking)
\item Negociación de varias de las características de la conexión.
\item Cómo indicar el comienzo y el final de un mensaje.
\item Formato de los mensajes.
\item Cómo actuar ante mensajes corruptos o con un formato incorrecto (corrección de errores)
\item Mecanismos de detección de pérdidas inesperada de la conexión y cómo comportarse ante estas.
\item Finalizar la sesión o conexión.
\end{enumerate}

En concreto el protocolo de Internet (IP) se utiliza en los extremos de la comunicación para mantener un flujo de datos a traves de una red de paquetes conmutados.

Precísamente debido a la naturaleza de estas redes los datos son divididos en cantidades coherentes a las limitaciones del medio (por ejemplo 1500 bytes para redes Ethernet), estos fragmentos de información se les denominan paquetes o datagramas. Además el protocolo no requiere que las rutas que deben seguir estos paquetes sean establecidas de antemano, es el propio protocolo el que encontrará la ruta idónea.

Con el protocolo IP se provee un sistema para la transmisión de datagramas no fiable (best effort), este m\'etodo de transmisión no garantiza resultados pero intentará utilizar la ruta más efectiva. Debe aclararse que IP no posee mecanismos para garantizar que la transmisión ha llegado a destino, aunque sí dispone de mecanismos para la detección de errores en los datos que contenga el paquete. Debido a la naturaleza dinámica de las rutas y a la hetereogeneidad de los dispositivos, es probable que los datagramas en que ha sido dividido el flujo de datos lleguen fuera de orden e incluso que llegue repetido; es tarea de los protocolos de transporte detectar estos sucesos.

A lo largo de la ruta es posible que la longitud maxima de transmisión (MTU) vaya cambiando (por ejemplo de 1500 bytes de un enlace Ethernet a los 576 de una conexión punto a punto). Es tarea del protocolo IP volver a fragmentar estos datagramas en otros más pequeños y recomponerlos cuando sea necesario, debe tenerse en cuenta que estos fragmentos pueden utilizar vías diferentes en según qué tramos de la ruta.

Para manejar estos incidentes el protocolo acompaña a las tramas de datos en los datagramas de unas cabeceras, estas llevan incluídas las direcciónes IP del origen y destino de la comunicación. Estas son requeridas por los dispositivos que retransmitirán los datos a trav\'es de las rutas para seleccionar el camino adecuado.

Actualmente el protocolo más utilizado en Internet es el IP versión 4 (IPv4 en adelante). Sin embargo ya se ha propuesto un sucesor, IPv6, llamado a eliminar las limitaciones que afectan a IPv4 desde su diseño. Una de estas nuevas características es el empleo de direcciónes de 128bits, que permitirá otorgar una dirección unívoca a más de 670 mil millones de dispositivos. 

Cabe señalar las versiónes 0 a la 3 del protocolo IP no llegaron a emplearse  y que la versión 5 se utilizó para un prototipo experimental. Además IPv4 dispone de diferentes implementaciónes que buscan mejorar su eficiencia o al menos limitar el efecto de sus deficiencias.

\section{Protocolos de transporte}

Basándonse en el nivel de Red (lo que proporciona una ruta de comunicación y un medio libre de errores inesperado en los datos recibidos) existe un nuevo nivel OSI. Los protocolos de este nivel tienen la responsabilidad de controlar la entrega en destino de los datos y en la medida de lo posible conseguirlo con una cantidad mínima de redundancia de datos.

\begin{wrapfigure}{l}{0.35\textwidth}
	\includegraphics[width=0.25\textwidth]{img/NivelesOSITransporte.eps}	
              \caption{Niveles OSI: protocolos de transporte}
  \label{fig:nivelesOSITransporte}
\end{wrapfigure}

Basándonos en esta jerarquía y situándonos sobre el protocolo de transporte los extremos de comunicación pueden dar las siguientes características por garantizadas :

\begin{enumerate}
	\item{Garantizar una transferencia libre de datos entre los interlocutores}
	\item{Mantener una ruta de comunicacion entre puntos que no est\'en directamente conexiónados}
	\item{Control de flujo y gestión del buffer}
	\item{Multiplexión de las vías de comunicación}
	\item{Recuperación y redirección}
\end{enumerate}

A continuación se van a estudiar los protocolos de transporte TCP y UDP, que aunque no son los únicos protocolos sobre IP sí son los más utilizados, prácticamente cualquier servicio ofrecido a través de Internet funcionará sobre uno de estos dos protocolos. Se va a profundizar en su funcionamiento para que el lector se de cuenta de las diferencias entre ambos y pueda percatarse de que entre los dos cubren casi cualquier necesidad de comunicación.

\subsection{Protocolo TCP}
El Transfer Control Protocol es el encargado de proporcionar un medio de comunicación orientado a conexión. Permite controlar que los mensajes llegan de un extremo a otro en el orden correspondiente. Además detecta y según el caso corrige fallos en la conexión, ya sean errores en los mensajes recibidos, pérdidas de tramas enteras o errores en parte de estas.

Las aplicaciónes sobre TCP envían y reciben flujos de datos de forma transparente (salvo error) a la aplicación que las utiliza. Es el propio protocolo el que fragmenta la tramisión según los requisitos del medio y organiza que la recomposición de los datos sea coherente sea cual sea el orden de llegada.

Las cabeceras del protocolo TCP son bastante complejas.

Los programas que utilizan una conexión TCP para transmitir datos lo hacen de manera transparente, envían el flujo de bytes y es el protocolo el que la divide en paquetes según la configuración de la capa de red, adjunta además su propia cabecera, que será indispensable para conseguir una recepción coherente de los datos, ya que incluye entre otros campos el número de secuencia. Durante la operación una pila TCP va recibiendo los paquetes desde la capa IP, los ordena y organiza segrún el número de secuencia. Para detectar la falta de paquetes y repetir la transferencia existe un mecanismo de asentimiento de la trasmisión: en la cabecera, un campo NACK indica al emisor de la información hasta que número de secuencia se han recibido todos los paquetes y se han recompuesto los datos. El mecasnismo de caducidad (timeout) se activará si en un cierto tiempo el emisor no ha recibido confirmación por parte del receptor.
\begin{figure}[h]
	\begin{center}
	\includegraphics[width=0.90\textwidth]{img/CabeceraTCP.eps}	
\end{center}
\caption{TCP: Diagrama de cabecera}
  \label{fig:CabeceraTCP}
\end{figure}

A continuación se desglosan los campos contenidos en las cabeceras:
\begin{enumerate}
	\item{Puertos de origen y destino: identifica a qué puerto de los extremos debe dirigirse el paquete.}
	\item{Número de secuencia: sirve para garantizar la coherencia y completud del flujo de datos que se está envíando. Dependiendo de si el flag SYN está o no activado, puede indicarnos si ese número de secuencia será el inicial para esa transferencia de datos o si está desactivado marcará el número de secuencia del primer byte de datos.}
	\item{NACK: si el paquete es de tipo ACK entonces el receptor está esperando que el siguiente paquete recibido sea el correspondiente al siguiente número de secuencia.}
	\item{Longitud de cabecera: especifica el tamaño de la cabecera en divisores de 32bits. A este campo tambi\'en se le denomina data-offset por ser el desplazamiento necesario para acceder a la trama de datos.}
	\item{Reservado: estos bits deberán dejarse a 0, están reservados para aplicaciones futuras del protocolo.}
	\item{Flags: estos 8 bits de control se utilizan para regular el funcionamiento del protocolo:
		\begin{enumerate}
			\item{CWR: Congestion Window Reduced, avisa al receptor de que se está produciendo congestión en la red y debe negociarse una reducción de la ventana del buffer.}
			\item{ECN-Echo: Se avisa al destino que puede emitir notificaciones ECN, este flag se usa durante la etapa de saludo.}
			\item{URG: Urgente, avisa de que el paquete debe ser tratado con prioridad en la pila.}
			\item{PSH: Push, hace que los datos almacenados en el buffer sean traspasados a la aplicación.}
			\item{ACK: Acknowlegde, hace que el número de acuse de recibo sea considerado por el receptor.}
			\item{RST: Reset, reinicializa la conexión}
			\item{SYN: Synchronize, obliga a que los números de secuencia est\'en sincronizados.}
			\item{FIN: Comunica el final del flujo de datos.}
		\end{enumerate}
	}
	\item{Ventana: es la capacidad de la ventana de recepción, indica en bytes la cantidad de datos que el receptor está esperando.}
	\item{Checksun: suma de comprobación que abarca tanto cabecera como datos.}
	\item{Urgente: Si está el flag URG activado indica el offset respecto del número de secuencia del último byte que debe considerarse urgente.}
	\item{Opciones: Campo de información ajena al contenido de los datos, debe ser múltiplo de 32bits}
	\item{Datos: trama con el segmento de datos que se espera en el destino.}
\end{enumerate}

\subsubsection{Funcionamiento}
El protocolo TCP basa su funcionamiento en una serie de procedimientos consecutivos:
\begin{enumerate}
	\item{Saludo o establecimiento de la conexión: Consistente en la negociación de 3 pasos en la que tambi\'en se establecen los parámetros clave de esta.}
	\item{Transferencia de los datos: en la que se van emitiendo asentimientos para confirmar la llegada de grupos de tramas}
	\item{Desconexión: para la que se procede a una negociación de 4 pasos}
\end{enumerate}

\begin{wrapfigure}{r}{0.45\textwidth}
	\includegraphics[width=0.35\textwidth]{img/TCPSaludo.eps}	
              \caption{Protocolo TCP: secuencia de saludo}
  \label{fig:TCPSaludo}
\end{wrapfigure}

Habitualmente para iniciar una conexión TCP un dispositivo cliente se comunica con un dispositivo servidor, que se encuentra escuchando en un puerto TCP concreto a través de la pila IP. Antes de que tanto el cliente como el servidor dispongan de un socke se realiza una negociación de 3 pasos. El cliente emite un paquete SYN al puerto específico del servidor, ahí el sistema operativo enviará la información al software que haya realizado el bind() a ese puerto. Si no existe ningún software escuchando se emitirá un paquete RST al cliente para que conozca el fallo de la operación. Si se ha alcanzado un puerto abierto el sistema responderá con un paquete SYN+ACK y para dar por establecida la conexión el cliente responderá a su vez con un paquete ACK. Es en este proceso cuando se elige al azar un número de secuencia que permitirá proceder correctamente en las operaciones de transferencia de datos.


Una vez establecida la conexión cliente y servidor dispondrán de un mecanismo de intercambio de datos muy similar al que se dispone cuando se abre un dispositivo de tipo carácter, el nivel de aplicación emitirá y recibirá datos de forma transparente y serán las capas de Transporte y Control las encargadas de que lleguen y se ordenen correctamente en destino.


El proceso de envío de datos requiere que se hayan determinado dos parámetros clave obligatorios en el establecimiento:
\begin{enumerate}
	\item{Número de secuencia: que corresponderá al primer byte de la trama contenida en el paquete y que se espera en el otro extremo. Cabe destacar que el número de secuencia volverá a 0 cuando haya sobrepasado el máximo}
	\item{Tamaño de ventana: es la cantidad de datos que pueden enviarse desde el emisor sin haber recibido confirmación de receptor.}
\end{enumerate}

Durante la transferencia el emisor envía un número de paquetes. Este número depende del número de asentimiento (que es el número de secuencia reconocido por el receptor), el número de secuencia de los paquetes que está envíando y la capacidad de la ventana de transferencia.

Normalmente el cliente irá recibiendo con un cierto orden los paquetes y modificando su propio número de secuencia. Periódicamente se informará al emisor con un paquete ACK del número de secuencia confirmado. Mientras tanto, este reenviará el conjunto de paquetes que correspondan a la ventana actual. Tambi\'en se emitirán ACKs cuando el paquete que se ha recibido complete a un conjunto.

En ciertas implementaciónes de TCP puede encontrarse una nueva función, el asentimiento selectivo, que permite avisar al emisor de qué paquetes son necesarios para completar el conjunto actual indicando cuales se han recibido.

Uno de los motivos más comunes de la pérdida de paquetes es la saturación del canal. Se emite más información de la que este puede enviar, con lo que los paquetes empiezan a ser descartados. Por este motivo TCP ha implementado sistemas para la detección de la saturación del canal, que regulan de una forma efectiva el tamaño de la ventana y el ritmo de emisión de los paquetes.

\begin{wrapfigure}{l}{0.45\textwidth}
	\includegraphics[width=0.35\textwidth]{img/TCPDespedida.eps}	
              \caption{Protocolo TCP: secuencia de desconexión}
  \label{fig:TCPDespedida}
\end{wrapfigure}

Durante la finalización de una conexión uno de los extremos emite un paquete FIN, la respuesta consiste en dos paquetes, un ACK y posteriormente un FIN, cuando el emisor de la despedida emita un ACK la conexión se dará por concluida.


\subsection{Protocolo UDP}

De entre los protocolos de transporte sobre IP, el User Datagram Protocol (UDP) es el mas básico de todos.

Orientado al simple envío de mensajes UDP ofrece un m\'etodo de operación muy sencillo para el acceso al protocolo de red. Sin embargo UDP no garantiza la recepción del mensaje, con lo que el origen de los datos no tiene forma de saber mediante el propio protocolo en qué estado se encuentra la transacción de datos, ni incluso si estos han salido a la red. Lo que sí garantiza UDP es el multiplexado, la verificación de errores y una minima proporción del tamaño de la cabecera respecto de la trama útil. 

Sin embargo si se desea obtener algún mecanismo para el control de la entrega de mensajes debe implementarse a nivel de aplicación.
\begin{figure}[h]
	\begin{center}
	\includegraphics[width=0.55\textwidth]{img/CabeceraUDP.eps}	
\end{center}
\caption{UDP: Diagrama de cabecera}
  \label{fig:CabeceraUDP}
\end{figure}

En su cabecera UDP sólo necesita de 2 campos obligatorios y otros 2 opcionales (con letras grises en el diagrama). Cada uno de estos datos ocupan 16 bits, con lo que las cabeceras tienen un tamaño fijo de 64bits u 8bytes, lo que lo hace muy ligero respecto de otros protocolos de transporte. Los campos para indicar el número de puerto sirven para identificar la aplicación que estará a la escucha, ya que suelen reservar un número de puerto pactado previamente. El puerto origen suele utilizarse para indicar dónde deben enviarse las respuestas, pero es opcional ya que muchas veces los protocolos basados en UDP no esperán retorno por parte del destino. Para dejar indicado que no hay puerto de retorno debe dejarse a 0 este campo. El otro campo opcional, el checksum, es una suma de verificación sobre los datos de cabecera (incluyendo las direcciónes y el protocolo en la cabecera IP, longitud y los datos) Este campo no suele ser deshabilitado. El campo de longitud recoge precisamente la longitud del propio segmento de datos incluido en el paquete.

Este protocolo es ampliamente utilizado en el streaming de multimedia y en los entornos de juegos en red, donde se busca alcanzar la mayor velocidad de transferencia y de que se garantice la solidez de los datos.

\section{Protocolos de aplicación}

\begin{wrapfigure}{l}{0.30\textwidth}
	%{figure}[h]
	\includegraphics[width=0.25\textwidth]{img/NivelesOSIAplicacion.eps}	
              \caption{Niveles OSI: protocolos de aplicación}
  \label{fig:nivelesOSIAplicacion}
\end{wrapfigure}

En este proyecto se van a implementar una serie de protocolos para demostrar la versatilidad de la plataforma y sobre todo la comodidad y la limpieza de código que aportan. Se pretende conseguir una plataforma que facilite la implementación de servicios para protocolos a nivel de Aplicacion.

Limitando la comunicación al nivel de aplicación, todos los protocolos existentes pueden resumirse como una secuencia de emisión y recepción de datos en una serie de etapas y formatos establecidos por el protocolo. 

De esta manera se puede entender al servicio como un autómata sensible al contexto para cada conexión que recibe. Orientando el diseño del servicio como una secuencia de pasos y que éstos sean lo más simples y claros posible, se ahorrará mucho tiempo y complejidad en la producción del código. 

Los protocolos elegidos para demostrar la idoneidad de la plataforma son los siguientes:

\subsection{Telnet}
Se trata de un cl\'asico obligado entre cualquier conjunto de servicios de red (o su sustituto Secure SHell). La función de este servicio consiste en proveer de autentificacion y acceso al control de las terminales de un sistema.

TELNET (TELecommunication NETwork) es un protocolo de red utilizado en conexiónes de Internet o en redes de area local (LAN). Fue desarrollado en 1969 y especificado en el RFC 15 y después estándarizado en el IETF STD 8, uno de los primeros estándares de internet.

El término telnet tambi\'en se refiere al software que implementa a la parte cliente del protocolo. Los clientes TELNET están disponibles en prácticamente cualquier plataforma. La mayoría de los equipos de red que dispongan de una pila TCP/IP tienen soporte  para algún tipo de servidor TELNET para permitir su configuración remota (incluyendo a los basados en Windows NT). Debido a los problemas inherentes para mantener la privacidad, TELNET se ha visto reemplazado ampliamente por SSH (Secure SHell).

El término ``hacer un telnet'' es la forma de llamar a establecer una conexión o utilizar TELNET u otras conexiónes TCP interactivas. Como ejemplo: ``Para cambiar tu contraseña, haz telnet al servidor y ejecuta el comando passwd''.

Muy a menudo un usuario hará telnet a un sistema tipo Unix o a un simple dispositivo de red como un router. Por ejemplo un usuario podría ``hacer telnet desde casa para mirar su correo en el colegio''. De la misma manera podria utilizar un cliente telnet para conectar desde su equipo de escritorio con sus servidores. Una vez que la conexión se ha establecido, el usuario podrá ingresar con sus datos de acceso y ejecutar comandos en el sistema remoto.

En algúnos sistemas la aplicación cliente puede utilizarse para realizar sesiones TCP en bruto. Comúnmente se cree que una sesion telnet que no incluye un IAC (el caracter 255) tiene la misma utilidad. Este no es el caso ya que debido a NVT (Terminales Virtuales de Red) con reglas especiales como el empleo constante de los caracteres 0 o 13.

\subsection{HTTP: HiperText Transfer Protocol}
Elaborado por el W3C y la IETF el HTTP es seguramente uno de los servicios de red más extendido en internet y en redes internas. Define las normas de comunicación entre los participantes del servicio (clientes, servidores y opcionalmente proxies). Servirá como ejemplo para abordar la programación de un protocolo m\'as avanzado y permita su uso desde los diversos tipos de navegadores.

El Hypertext Transfer Protocol (HTTP) es un protocolo de comunicaciones para transferencia de información a trav\'es de Internet. Su utilización para recuperar documentos de texto vinculados (hipertexto) ha llevado al establecimiento de la World Wide Web.

El desarrollo del HTTP fue coordinado por el Consorcio World Wide Web (W3C) y la Internet Engineering Task Force (IETF), culminando en la publicación de una serie de RFCs, siendo el más destacable el RFC 2616, que en Junio de 1999 definió el HTTP versión 1.1, que es la que más ampliamente se utiliza en la actualidad.

HTTP es un estándar petición/respuesta entre un cliente y un servidor. El cliente será el usuario final mientras que el servidor es el sitio web (web site). El cliente, realizando una petición HTTP mediante un navegador web, araña web u otras herramientas, se le denomina user agent. El servidor correspondiente, que almacena o crea recursos como ficheros HTML e imágenes, es denominado servidor de origen. Entre el user agent y el servidor origen pueden aparecer varios intermediarios, como son los proxys, pasarelas y tuneles. El HTTP no está limitado a su utilización sobre TCP/IP y sus capas, más aún es la aplicación más extendida en Internet. Ciertamente HTTP puede implementarte sobre otros protocolos en Internet en otras redes. HTTP sólo asume que se encuentra sobre un protoclo de transporte confiable, con lo que HTTP puede utilizarse sobre cualquier protocolo que lo garantice.

Normalmente es el cliente HTTP el que inicia la petición. Se establece una conexión TCP a un puerto particular en un servidor (el puerto 80 por defecto) El servidor HTTP escuchando en ese puerto esperará a que el cliente emita el mensaje de petición. Una vez recibida la petición el servidor responde con una línea de estado, como por ejemplo ``HTTP/1.1 200 OK'',  un mensaje propio, el cuerpo de lo que probablemente sea el fichero solicitado, mensajes de error si procede y otras informaciónes.

La razón por la que HTTP se basa en TCP y no en UDP es debida a la cantidad de datos que se generan al enviar una página web y a que TCP provee control de transmisión, envría los datos en orden y provee corrección de errores.

Los recursos a los que se puede acceder mediante HTTP se identifican mediante Identificadores Unificados de Recursos (URIs) y en concreto Localizadores Unificador de Recursos (URLs).


\subsection{SIP: Session Initiation Protocol} 

Es un protocolo desarrollado por el IETF MMUSIC Working Group en la búsqueda de un estándar para iniciar, finalizar o modificar sesiones interactivas de usuario, que se emplearan para contactar con dichos usuarios. Normalmente se utiliza en conjunción con otros servicios, principalmente multimedia (video, voz, mensajeria instantanea). Se ha convertido en el protocolo de señalización para voz por IP más utilizado junto al H.232.

El Session Initiation Protocol es un protocolo de señalización, ampliamente utilizado para iniciar y desconectar sesiones de comunicaciones multimedia, como llamadas de voz y video a trav\'es de internet. Otras aplicaciones interesantes incluyen conferencias de video, streaming multimedia, mensajeria instantánea, información de presencia y juegos online. En Noviembre del 2000 SIP fue adoptado como protocolo de señalización para 3GPP y elemento permanente de la arquitectura IMS para streaming multimedia sobre IP para telefonos celulares.

Este protocolo puede utilizarse para crear, modificar y finalizar sesiones unicast o multicast consistentes en uno o varios flujos de medios. La modificacion puede suponer cambiar direcciónes o puertos, invitar a otros participantes, añadir o retirar flujos de medios, etc.

SIP puede situarse sobre los proctolos TCP, UDP o SCTP. Fue originariamente diseñado por Henning Schulzrinne (Universidad de Columbia) y Mark Handley (UCL) en 1996. La última versión de la especificación es el \cite{RFCSIP} RFC 3261 del IETF SIP Working Group.

Cabe destacar que SIP funciona en modo texto, lo que hace más facil analizar su funcionamiento.

\chapter{Análisis y Diseño}
\section{Análisis}
El modelo Cliente-Servidor es tan básico como antiguo. Se pueden considerar que los primeros sistemas de este tipo eran los teletipos utilizados en las universidades para emitir programas a los equipos que allí habían instalados y recibir posteriormente sus resultados. A diferencia de hoy, aquellos sistemas funcionaban directamente sobre enlaces dedicados y cada uno de estos teletipos disponía de una conexión permanente.

\begin{wrapfigure}{l}{0.50\textwidth}
	%{figure}[h]
	\includegraphics[width=0.45\textwidth]{img/FlujoServicio.eps}
              \caption{Niveles OSI}
  \label{fig:nivelesOSI}
\end{wrapfigure}

Sin embargo, la implantación de sistemas de red por capas, enlaces no dedicados y sobre todo la diversificación de equipos mucho mas baratos y potentes han modificado el panorama de manera importante: Además de diversificarse los tipos de servicios era posible que varios de ellos coexisitieran en el mismo equipo.

En el contexto de los sistemas informáticos un protocolo es un conjunto de reglas predefinidas, cuyo proposito es estándarizar actividades y procesos. Siguiendo un mismo protocolo se garantiza que se mantendrá la compatibilidad entre los sistemas involucrados, independientemente del medio sobre el que est\'en en contacto, posiblemente otros protocolos.

La forma cl\'asica de programar un servicio consiste en un bucle de escucha que inicia subprocesos para cada conexi\'on entrante y que finaliza cuando esta acaba o se produce un error. Se presentan dos entidades en este caso; la del servicio, que incluirría las rutinas para iniciar la escucha y el acceso a los datos, y la del manipulador, que atiende la conexión siguiendo las pautas del protocolo.

\subsection{Servicio}

Al arrancar un servicio antes de iniciar el bucle de escucha deben realizarse una serie de procedimientos:
\begin{enumerate}
	\item La lectura de parámetros desde línea de comandos
	\item La lectura de parámetros desde el archivo de configuración
	\item El registro de actividad en el/los archivo(s) pertinente(s)
	\item Preparar el acceso a los datos necesarios, ficheros o bases de datos
\end{enumerate}

\subsubsection{Parámetros}
Existen parámetros que son comunes prácticamente a cualquier servicio, por ejemplo:
\begin{enumerate}
	\item Fichero de configuraci\'on.
	\item N\'umero de puerto para la escucha.
	\item N\'umero m\'aximo de conexiónes simultáneas.
	\item Ficheros de registro, eventos, errores, etc.
	\item Nivel de locuacidad (verbosity) en los registros.
\end{enumerate}
O parámetros particulares para según qué tipos de servicio:
\begin{enumerate}
	\item Acceso al medio de datos.
	\item Parámetros de configuraci\'on concretos para este servicio.
\end{enumerate}
Debe tenerse en cuenta que los parámetros en el fichero de configuración tienen menor prevalencia que los indicados por línea de comandos, salvo el que especifique precisamente qué fichero de configuracion debe leerse.

\subsubsection{Ficheros de configuración}
Debe acordarse una estructura común a todos los ficheros de configuración que se parsearán desde la plataforma pero permitiendo a la vez mantener la genericidad suficiente como para no perder la flexibilidad que haga este sistema util a cualquier implementación de servicios y que a su vez permita que los usuarios puedan entender el fichero de forma clara y manipularlo facilmente.

Se espefican con ese fin las siguiente sintaxis:


\[<nombre parametro>=<valor>\{,<valor-N>\}\]


Para los valores que deben utilizar los parámetros se pueden utilizar comodines para ampliar la versatilidad:
\begin{enumerate}
	\item \%H - Hostname
	\item \%i - Ip de la conexión entrante
	\item \%p - Puerto de origen de la conexión
	\item \%d - fecha actual
	\item \%t - hora actual
\end{enumerate}

\subsubsection{Locuacidad}
Para que puedan establecerse mensajes de depuración a distintos niveles debe adoptarse un sistema de categorías o prioridades para estos. En cada etapa o proceso del servicio y del manipulador se emiten mensajes que incorporan el nivel de locuacidad para el que son generados, será la clase encargada de mostrar mensajes la que los muestre segun si el nivel de estos es menor o no que el indicado.
Se proponen los siguientes niveles
\begin{enumerate}
	\item 0 - Básico: mensajes de operaciones mínimo, inicio del sistema, errores en los procedimientos.
	\item 1 - Moderado: mensajes comunes, entrada en servicio de un manipulador y puntos clave del desarrollo de la atención.
	\item 2 - Productivo: indica la entrada en la mayoría de las etapas de un servicio. Se amplian los detalles de los mensajes de error.
	\item 3 - Expresivo: indica la entrada a cada etapa del servicio, se detalla el contexto de cada mensaje de error.
	\item 4 - Locuaz: detalla el contexto de cada etapa.
\end{enumerate}

\subsubsection{Registro}
Con la intención de simplificar la tarea de gestionar la salida de mensajes, bien a la salida de la consola o a ficheros de registro, deben implementarse clases destinadas a tal fin, que vuelquen o no los mensajes al medio según la locuacidad que se ha fijado y que en caso de que el medio predeterminado falle (por falta de espacio o cambio de permisos) sea capaz de cambiar a otro (indicado en la configuración o a los medios salida por pantalla dedicados a tal fin).


\begin{figure}[h]
	\includegraphics[width=0.95\textwidth]{img/DiagramaClasesAnalisis.eps}
              \caption{Diagrama de Clases de Análisis}
     \label{fig:DiagramaClasesAnalisis}
\end{figure}


\subsection{Manipulador}
Precisamente es la naturaleza de un protocolo, como un conjunto ordenado de etapas en las que se organiza el flujo de información entre los sistemas, la que permite abstraer al programa servidor como un autómata sensible al contexto. Cada etapa del manipulador equivale al estado del autómata y pueden realizarse un conjunto determinado de acciones:
\begin{enumerate}
	\item Recibir datos desde la conexión
	\item Emitir datos a la conexión
	\item Tratar, almacenar o recuperar datos
	\item Avanzar, saltar o retroceder a otra etapa
\end{enumerate}

La recepción de los datos puede además controlarse mediante expresiones regulares según las especificaciónes del protocolo, detectando rapidamente errores en la entrada. Debe facilitarse además la adopción de distintos tipos de intercambio de datos, controlados, formato en bruto o encriptados para evitar reimplementaciónes de esta clase de rutinas.

En el diseño del manipulador debe tenerse en cuenta que normalmente existe un orden convencional en las etapas. Previsiblemente estas deberían contener un número limitado de procedimientos, para reducir la complejidad.

Durante la implementación de los protocolos ha aparecido la necesidad de trabajar sobre UDP. Para permitir esta funcionalidad y mantener un diseño eficiente se ha optado por dividir el manipulador en tres nuevas clases que permitieran trabajar tanto sobre el protocolo TCP como UDP y en concordancia a sus características:
\begin{description}
	\item[Handler]{la clase Handler primitiva se centra en la gestión de estados, el tránsito entre estos, y su inicialización.}
	\begin{description}
		\item[TCPHandler]{esta clase que hereda de Handler contiene una versión especial de las rutinas de emisión y recepción de datos. Se inicializa pasando el hash del socket.}
		\item[UDPHandler]{Cada vez que un datagrama llega al servidor se instancia al manipulador, integrando la dirección de origen del datagrama y los datos que portaba, esta clase tendra sus propias rutinas de emisión y recepción. Debe tenerse en cuenta que en este tipo de manipulador se hace necesario algún sistema que permita recuperar desde el servidor en qué estado se encontraba al finalizar la última transmisión.}
	\end{description}
\end{description}
\subsection{Flujos de los protocolos}
A continuación se va a espeficicar el flujo de los protocolos con los que se va a probar la plataforma.

\subsubsection{Telnet}
\begin{figure}[h]
	\includegraphics[width=0.95\textwidth]{img/DiagramaFlujoTelnet.eps}
              \caption{Flujo de desarrollo del protocolo Telnet}
  \label{fig:DiagramaFlujoTelnet}
\end{figure}

El protocolo Telnet tiene un flujo básico de desarrollo muy simple:
\begin{enumerate}
	\item Se establece la conexión con el cliente
	\item Se presenta el diálogo de petición de contraseña y se espera a que se introduzcan los datos.
	\item Se checkea la contraseña contra la base de datos correspondiente
	\item Se solicita el comando a ejecutar en el sistema
	\item Se ejecuta el comando pertinente y se muestra su salida. y se vuelve al paso 4.
\end{enumerate}
Existe un pequeño conjunto de pasos alternativos:
\begin{enumerate}
	\item (4.Alternativo) El usuario debe repetir la autentificación.
	\item (5.Alternativo) Se ha solicitado finalizar la sesión con lo que procedemos a la desconexión.
\end{enumerate}
\subsubsection{HyperText Transfer Protocol}
\begin{figure}[h]
	\includegraphics[width=0.95\textwidth]{img/DiagramaFlujoHTTP.eps}
              \caption{Flujo de desarrollo del protocolo HTTP}
  \label{fig:DiagramaFlujoHTTP}
\end{figure}
El protocolo HTTP/1.1 tiene un flujo básico bastante más amplio, ya que después de recibir la orden las rutinas que atenderán el comando difieren drásticamente. En consecuencia deberán implementarse nuevos estados para cada tipo de comando.
\begin{enumerate}
	\item Se establece la conexión con el cliente
	\item Se muestra la información del servidor
	\item Se reciben las cabeceras y el comando
	\item En el estado de atención se recibe el resto de la información (si procede)
	\item Se responde informando del estado.
\end{enumerate}
Aunque la conexión pueda perderse inesperadamente en cualquier momento, es en el momento de esperar el comando cuando se produciría una desconexión correcta.
\subsubsection{Session Initialization Protocol}
El protocolo SIP es responsable de varias tareas, aunque puede operar sobre UDP la implementación sobre BLAS solo funcionará sobre UDP.

Es precisamente en este punto por la necesidad de trabajar sobre UDP cuando se ha tomado la decisión de dividir el manipulador en tres nuevas clases que permitieran trabajar tanto sobre el protocolo TCP como UDP y en concordancia a sus características.
\begin{figure}[h]
	\includegraphics[width=0.95\textwidth]{img/DiagramaFlujoSIP.eps}
              \caption{Flujo de desarrollo del protocolo SIP}
  \label{fig:DiagramaFlujoSIP}

\end{figure}

\begin{enumerate}
	\item{Registro(REGISTER): El usuario se da de alta en el sistema y figura en el directorio de usuario.}
	\item{Invitación(INVITE): Dirigido a un usuario se le autoriza a acceder a un medio compartido. Debe aceptarse con ACK o denegarse con CANCEL.}
	\item{Opciones(OPTIONS): Solicita al servidor el listado de las funcionalidades.}
	\item{Cierre(BYE): Avisa de que va a procederse con la desconexión.}
\end{enumerate}


\subsection{Acceso a datos}
Muchos servicios tienen la necesidad de leer y escribir en medios de datos centralizados, por eso es importante diseñar según se debe hacer un esfuerzo en desarrollar un modelo de acceso a datos que permita una lectura lo más transparente posible, facilitando la lectura del código. 

Normalmente existen unos tipos limitados de medios de datos:
\begin{enumerate}
	\item{Registos unificados volátiles: Son medios de datos que se borrarán cuando se desactive el servicio, deben permitir el acceso concurrente por parte de los hilos. Este tipo de medios sería muy adecuado para sistemas de chat, etc.}
	\item{Accesos a bases de datos: Python tiene soporte para acceder a muchos tipos de bases de datos: Mysql, Postgresql, ODBC, etc. Sin embargo, diseñar un acceso a datos mediante objetos que eviten la manipulación de peticiones SQL en el código de la atención del servicio será básico para la comprensión del código y su depuración.}
	\item{Acceso remoto a datos: En ocasiones los datos que se necesitan estarán en sistemas remotos, accediendo a ellos mediante conexiónes IP/TCP y normalmente sobre estos m\'etodos HTTP, SOAP o REST. Al igual que en otros medios de acceso es importante que el m\'etodo de acceso se abstraiga del código de atención del servicio}
\end{enumerate}
En definitiva y aunque para cada tipo de servicio el modelo de acceso a datos varía considerablemente se pueden establecer las siguientes líneas para el analisis y la orientación que tomará el sistema:
\begin{enumerate}
	\item{Claridad: Debe evitarse la molesta aparición de líneas SQL, peticiones HTTP, XML y similares en el código.}
	\item{Orientación a objetos: Un buen modelo de acceso a datos reducirá sensiblemente el tiempo que se requiera para depuración y posteriores.}
	\item{Manejo de errores: Es importante integrar el manejo de excepciones en las rutinas de adquisición de datos ya que no estarán exentas de fallos.}
	\item{Oportunidad de acceso: Deben elegirse adecuadamente en qué momentos se accederá a los datos, para no producir latencias en puntos del proceso sensibles al tiempo de respuesta. Además si el dispositivo no dispone de control de acceso al medio debe implementarse algún m\'etodo que controle la concurrencia.}
	
\end{enumerate}

\section{Diseño}

\subsection{Librería principal}
Existe una parte común a toda la plataforma que contiene las clases abstractas, puede verse su diagrama de clases de diseño en la figura \ref{fig:DiagramaClasesDiseñoCore}

\begin{figure}[h]
	\includegraphics[width=0.80\textwidth]{img/DiagramaClasesDisennoCore.eps}
	\caption{Diagrama de Clases de la librería principal} 
	      \label{fig:DiagramaClasesDiseñoCore}
\end{figure}

En estas clases se incorporarán todas las funcionalidades que puedan emplearse desde cualquier implementación de un servicio. Para simplificar el procedimiento de herencia de componentes se incluirán todas en el archivo core.py, que acompañaría al archivo que contenga el código del servicio en sí mismo en cada despliegue que se haga a posteriori del sistema.
\subsubsection{Server}
Esta clase incluye las rutinas necesarias para la inicialización y configuración del servicio:
\begin{enumerate}
	\item Carga y parseado de los parámetros de línea de comando.
	\item Carga e interpretación de los archivos de configuración.
	\item Reserva del socket al que se conectarán los clientes del servicio.
	\item Bucle principal de inicializacion y despacho de los hilos.	
	\item Inicialización de los registros de eventos y errores del sistema.
	\item Recopilación de las cadenas de documentación relacionadas con cada parámetro del sistema.
	\item Inicialización de los medios de acceso a datos comunes (si procede). 
\end{enumerate}
\subsubsection{Error}
Esta clase que hereda de la clase de sistema Exception se utiliza como tipo de datos por defecto en caso de que algúno de los procesos o rutinas del sistema no pueda realizar su función, en estos casos devolverá un objeto de clase Error.

Además Error contiene 2 datos importantes para la infraestructura:
\begin{description}
	\item[msg]Cadena que contiene una cadena explicando el suceso que originó el error.
	\item[level]Entero que se utiliza para saber si la gravedad del suceso obliga a su aparición en los registros.
\end{description}
Los m\'etodos son una sobrecarga de los m\'etodos básicos de la clase Exception:
\begin{description}
	\item[\_\_init\_\_]Que inicializa el objeto proveyendo de la información con el mensaje de error y el nivel de importancia.
	\item[\_\_str\_\_]Devolverá la cadena con la explicación del error y el nivel de importancia cuando se necesite imprimirlo en el registro.
\end{description}
\subsubsection{Log}
En esta versión del registro solo se volcarán los eventos y errores a salida estándar o a ficheros. Para reducir el acoplamiento en las llamadas en los objetos de registro integran los siguientes datos durante su tiempo de vida:
\begin{description}
	\item[file]File salvo que su valor sea None será el descriptor de fichero donde se volcará la información.
	\item[level]Int indicará el nivel de importacia que debe igualarse o superarse para que el evento se vuelque en el registro.
\end{description}
Los m\'etodos propios de los objetos tipo Log son:
\begin{description}
	\item[\_\_init\_\_()]M\'etodo de inicialización del registro, indicando el nombre del fichero de volcado y el nivel mínimo de importancia. Si la apertura del fichero falla se pasarán a volcar los datos a la salida estándar.
	\item[put()]Con este m\'etodo se vuelcan eventos al registro, además del mensaje debe acompañarse del nivel de importancia del evento. Para simplificar su invocación normalmente se utiliza un puntero desde self.log[``report''].put() a self.report() con lo que las llamadas son mucho más cortas.
\end{description}
\subsubsection{Handler: UDP y TCP}
Seguramente las clases más importantes que se incorporan en un servicio:
\begin{enumerate}
	\item Handler: Es la clase principal, hereda de la clase hilo (Thread) y sus principales funcionalidades son:
		\begin{enumerate}
			\item Controlar el avance, retroceso y tránsito entre estados del manipulador en ejecución.
			\item Sobrecargar las clases mínimas de la clase Thread para un funcionamiento coherente.
		\end{enumerate}
	\item TCPHandler: Versión del manipulador que contiene los atributos y m\'etodos concretos para tratar con el socket que les corresponda. En este caso basta con guardar el puntero al Socket, ya que es lo único que necesitan las rutinas send() y receive() para enviar y recibir datos con el cliente.
	\item UDPHandler: Versión del manipulador destinada a atender las peticiones UDP. En el caso de protocolo UDP es más complicado ya que no existe un Socket como tal. En su lugar se guarda la dirección ip y puerto de donde procedía la comucación y ademas el buffer de los datos recibidos, con lo que los procedimientos de envío y recepción de datos tienen las siguientes particularidades:
		\begin{enumerate}
			\item send(): debe crear un nuevo socket UDP con los datos de conexión que posee, estos pueden facilitarse desde los parámetros o utilizar los que figuran como origen de los datos. No existe confirmación sobre si los datos han llegado por lo que la aplicación debe buscar su forma de confirmar la transmisión.
			\item receive(): Todos los datos que puedan llegar al hilo de atención llegan de una sola vez desde el momento en que se inicia, se van consumiendo según especifique el patrón que se pasa como parámetro. Si el buffer de datos está vacío se devolverá un objeto Error.
		\end{enumerate}
\end{enumerate}
\subsection{Servicio de ejemplo}
A continuación se presenta un ejemplo de como se realiza la implementación de un servicio heredando de las clases de BLAS. En la figura \ref{fig:DiagramaClasesDiseñoParticular} puede observarse como se relacionan las clases.

\begin{figure}[h]
	\includegraphics[width=0.80\textwidth]{img/DiagramaClasesDisennoParticular.eps}
	\caption{Diagrama de Clases de un servicio de ejemplo} 
	      \label{fig:DiagramaClasesDiseñoParticular}
\end{figure}
El arranque del sistema se realiza de la siguiente manera:
\begin{enumerate}
	\item Se carga el fichero con el intérprete de Python, presumiblemente el fichero se llamaría particular.py.
	\item Una vez finalizadas las importaciones de los modulos se cargan las definiciones de clases y sus m\'etodos.
	\item Cuando se llega a la zona de ejecución se instancia un objeto ParticularServer con los argumentos recibidos por línea de comandos. Despu\'es se invoca al m\'etodo mainloop indicándole la clase de manipulador que debe instanciar.
	\item Durante la inicialización de un objeto ParticularServer se instancian al mismo tiempo los objetos de registro, a la vez que se llama a la inicializacion de Server, que será común a todos los servidores. Aquí se parsearán las opciones de la línea de comandos, cuyas directrices estarán distribuidas en el código de ParticularServer y Server en m\'etodos que inician su nombre con ``config\_'' seguido del nombre del parámetro, en su campo de documentación se incluye el prefijo que debe utilizarse en la línea de comandos para modificar estos parámetros.
	\item En mainloop() discriminando el tipo de manipulador(TCP o UDP) abrirá el tipo de socket pertinente e iniciará un bucle while. Dentro de estas conexiónes se irán atendiendo por parte de los manipuladores. Para que los manipuladores puedan hacer su trabajo deben primero inicializarse y luego emitir la orden de arranque.
	\item Al inicializar el hilo del manipulador se le aporta bien el socket de conexión para los tipo TCP y el buffer y la dirección de origen para los UDP. El m\'etodo start() que se hereda de la clase Thread iniciará la ejecución del hilo que se desarrollará a lo largo de los estados que se deban seguir para atender la petición.
	\item la mayor parte del código del manipulador serán m\'etodos cuyo nombre empiece port ``step\_'' seguido del identificador del paso en si mismo, en cada paso debe indicarse si se pasa al siguiente, al anterior o se salta a otro; de otra manera se repetirá el mismo paso.
\end{enumerate}
\subsection{Servicio Telnet}
Para imitar un servicio de terminal interactiva con autentificación 
			  \ref{fig:DiagramaClasesDisennoTelnet}
\begin{figure}[h!]
		\begin{center}
				\includegraphics[angle=90,width=0.90\textwidth]{img/DiagramaClasesDisennoTelnet.eps}	
			\end{center}
			\caption{Diagrama de Clases de Diseño: Servicio Telnet}
			  \label{fig:DiagramaClasesDisennoTelnet}
\end{figure}

\subsection{Servicio HTTP}

\begin{figure}[h!]
		\begin{center}
				\includegraphics[angle=90,width=0.90\textwidth]{img/DiagramaClasesDisennoHTTP.eps}	
			\end{center}
			\caption{Diagrama de Clases de Diseño: Servicio HTTP}
			  \label{fig:DiagramaClasesDisennoHTTP}
\end{figure}

\subsubsection{Bifurcación y flujo de estados} 
Una vez que el servidor ha recibido la trama con la petición e instanciado el hilo de atención correspondiente se inicia el siguiente proceso:
\begin{description}
	\item[Request] En este paso se recibe la primera línea de la petición, se informa en el registro del origen de la transmisión y se almacena el comando en los datos del hilo. Se pasa a la etapa Run.
	\item[Headers] Este paso irá recolectando y parseando las cabeceras de las peticiones, no se pasará al siguiente paso Run hasta que se encuentre con una cabecera en blanco.
	\item[Run] La función de este estado es elegir a cual se pasará según el comando que se ha recibido.
	\begin{description}
		\item[Run\_Get] En este paso se relativizará la ruta solicitada a la que está configurada como raiz del servidor, además si no se ha indicado un fichero se intentará localizar ``index.html''. Si al intentar la apertura del fichero se produce una excepción será capturada y se emitirá al cliente una respuesta ``404 Not Found''. En caso de que la apertura del fichero sea correcta se emitirá antes un mensaje ``200 OK'', las cabeceras de información mínimas, incluyendo el tamaño del contenido a transmitir y finalmente el cuerpo de la petición. A continuación se indicará que el estado siguiente es ``End''.
	\end{description}
	\item[End] Esta parte del proceso guardará la información obtenida de los pasos anteriores y emitirá el suceso del fin de la petición al registro de eventos.
\end{description}
Puede encontrarse el diagrama de clases de diseño en \ref{fig:DiagramaClasesDisennoHTTP} 
\subsection{Servicio SIP}
\begin{figure}[h]
		\begin{center}
				\includegraphics[angle=90,width=0.90\textwidth]{img/DiagramaClasesDisennoSIP.eps}	
			\end{center}
			\caption{Diagrama de Clases de Diseño: Servicio SIP}
			  \label{fig:DiagramaClasesDisennoSIP}
\end{figure}
El diagrama de diseño de clases del servicio SIP esta en la figura \ref{fig:DiagramaClasesDisennoSIP}
\subsubsection{Bifurcación y flujo de estados} 
Una vez que el servidor ha recibido la trama con la petición e instanciado el hilo de atención correspondiente, se inicia el siguiente proceso:
\begin{description}
	\item[Request] En este paso se recibe la primera línea de la petición, se informa en el registro del origen de la transmisión y se almacena el comando en los datos del hilo. Se pasa a la etapa Run.
	\item[Headers] Este paso irá recolectando y parseando las cabeceras de las peticiones. No se pasará al siguiente paso Run hasta que se encuentre con una cabecera en blanco.
	\item[Run] La función de este estado es elegir a cual se pasará según el comando que se ha recibido.
	\begin{description}
		\item[Run\_Register] Este paso acaba procesando cualquier comando Register. Si no hay autentificación, la solicita generando antes un código ``nonce'' de desafio para que el cliente responda. A continuación emite un ``401 Unauthorized'' con la información del desafio. En caso de que el cliente haya aportado autentificación se llama al m\'etodo ``digest'' para realizar el contraste del campo ``response'' y la respuesta producida por el propio servidor. A continuación se procederá al estado ``End''.
		\item[Run\_Subscribe] En este estado se guarda información de usuario en el registro para aviso de eventos. A continuación se pasa al estado ``End''.
		\item[Run\_Invite] En este estado, si tanto el usuario origen como destino estan validados, se pasa al estado ``Invite\_Request''. En caso contrario se pasará a ``End''.
		\begin{description}
			\item[Invite\_Request] En este estado se enviará una petición al destinatario para que acepte la solicitud, se pasará al estado ``End'' después de marcar la invitacion como pendiente.
		\end{description}
		\item[Run\_Ack] Se revisa en el registro de invitaciones pendientes si existe registro con esa referencia. De ser así se enviarán una confirmación al emisor de la misma y se pasará al estado ``End''.
	\end{description}
	\item[End] Esta parte del proceso guardará la información obtenida de los pasos anteriores y emitirá el suceso del fin de la petición al registro de eventos.
\end{description}
\subsubsection{Autentificación}
El procedimiento de autentificación en SIP se realiza a trav\'es de un mecanismo heredado de HTTP Digest. Para que se produzca la autentificación se desarrolla la siguiente secuencia:
\begin{enumerate}
	\item El cliente pide registrarse en el servicio. No provee m\'etodo de contraste algúno.
		\scriptsize
		\begin{verbatim}
		REGISTER sip:192.168.1.100 SIP/2.0
		Tue Aug 26 21:09:38 2008:192.168.1.11:5072:current state:receiving param
		CSeq: 127 REGISTER
		Via: SIP/2.0/UDP 192.168.1.11:5072;branch=z9hG4bK2686af38-1072-dd11-9855-0016e6dfa1a5;rport
		User-Agent: Ekiga/2.0.12
		From: <sip:edorka@192.168.1.100>;tag=4279af38-1072-dd11-9855-0016e6dfa1a5
		Call-ID: 205faf38-1072-dd11-9855-0016e6dfa1a5@Newton
		To: <sip:edorka@192.168.1.100>
		Contact: <sip:edorka@192.168.1.11:5072;transport=udp>
		Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
		Expires: 3600
		Content-Length: 0
		Max-Forwards: 70
		\end{verbatim}
		\normalsize
	\item El servidor contesta con un error ``401 Unauthorized`` y provee en las cabeceras del desafio de autentificación.
		\scriptsize
		\begin{verbatim}
		SIP/2.0 401 Unathorized
		WWW-Authenticate: Digest realm=``192.168.1.100'', nonce=``ff8c..'', qop=``auth''
		CSeq: 102 REGISTER
		Via: SIP/2.0/UDP 192.168.1.11:5069;branch=z9hG4bKc2448342-...;rport=5069
		From: <sip:edorka@192.168.1.100>;tag=5c418342-f671-dd11-9855-0016e6dfa1a5
		Call-ID: 00a1a017-e771-dd11-9855-0016e6dfa1a5@Newton
		To: <sip:edorka@192.168.1.100>;tag=5c418342-f671-dd11-9855-0016e6dfa1a5
		Contact: <sip:edorka@192.168.1.11:5069;transport=udp>
		Content-Length: 0
		Server: PythonSIP prototype
		\end{verbatim}
		\normalsize
	\item El cliente reintenta el registro en el servidor incluyendo en la cabecera un campo ''Authorization'' con los datos que ha empleado para calcular el campo ``response''.
		\scriptsize
		\begin{verbatim}
		REGISTER sip:192.168.1.100 SIP/2.0
		CSeq: 129 REGISTER
		Via: SIP/2.0/UDP 192.168.1.11:5072;
			branch=z9hG4bK2870b438-1072-dd11-9855-0016e6dfa1a5;rport
		User-Agent: Ekiga/2.0.12
		Authorization: Digest username=``edorka'', realm=``192.168.1.100'', 
			nonce=``ff8cf8e764fca9134c1cd5499bc4684b'', uri=``sip:192.168.1.100'', 
			algorithm=md5, response=``365cf4061c002b09c75408a4907ac911'', 
			cnonce=``3261b438-1072-dd11-9855-0016e6dfa1a5'', 
			nc=``00000001'', qop=``auth''
		From: <sip:edorka@192.168.1.100>;tag=4279af38-1072-dd11-9855-0016e6dfa1a5
		Call-ID: 205faf38-1072-dd11-9855-0016e6dfa1a5@Newton
		To: <sip:edorka@192.168.1.100>
		Contact: <sip:edorka@192.168.1.11:5072;transport=udp>
		Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
		Expires: 3600
		Content-Length: 0
		Max-Forwards: 70
		\end{verbatim}
		\normalsize
	\item Si el servidor da por buena la respuesta al desafio, despu\'es de calcularlo por su cuenta emitirá una respuesta ``200 OK'' en referencia a la última petición.
		\scriptsize
		\begin{verbatim}
		SIP/2.0 200 OK
		CSeq: 107 REGISTER
		Via: SIP/2.0/UDP 192.168.1.11:5069;
			branch=z9hG4bK460a1e59-0572-dd11-9855-0016e6dfa1a5;rport=5069
		From: <sip:edorka@192.168.1.100>;tag=da541c59-0572-dd11-9855-0016e6dfa1a5
		Call-ID: 00a1a017-e771-dd11-9855-0016e6dfa1a5@Newton
		To: <sip:edorka@192.168.1.100>;tag=da541c59-0572-dd11-9855-0016e6dfa1a5
		Contact: <sip:edorka@192.168.1.11:5069;transport=udp>
		Content-Length: 0
		Server: PythonSIP prototype
		\end{verbatim}
		\normalsize
\end{enumerate}
Para calcular el response correcto se ha implementado un m\'etodo digest() al que se pueden pasar como argumentos el m\'etodo que lo ha llamado y la contraseña que se debe comprobar, el proceso de ``digestión'' es el siguiente
\begin{enumerate}
	\item \begin{math} S1 = MD5(<username>:<realm>:<password>) \end{math}
	\item \begin{math} S2 = MD5(<metodo>:<URI>:) \end{math}
	\item \begin{math} RESP = MD5(S1:<nonce>:<nc>:<cnonce>:<qop>:S2) \end{math}
\end{enumerate}
\section{Manual de usuario}
Para ejecutar cualquiera de los servicios debe situarse en la raiz del CD que acompaña a la memoria y ejecutar el interprete de Python indicando el fichero del servicio. Por ejemplo:
\begin{verbatim}
Python telnet.py
Python http.py
Python sip.py
\end{verbatim}.

Debe tenerse en cuenta que para puedan realizarse operaciones de escritura en el medio con información de los registros de eventos y errores, deben copiarse al disco duro los ficheros contenidos en el CD y ejecutar desde ahí. 

El interprete incluido en el CD puede funcionar sin instalación. Sin embargo se ha incluido una copia del instalador para windows de la última versión disponible de Python.

Al ser multiplataforma el interprete y con él, el entorno, sabiendo que las reglas y permisos de cada sistema serán diferentes y para evitar problemas en la ejecución se han modificado los puertos de escucha, con lo que telnet estará a la escucha en el puerto TCP 2300 y el servidor HTTP en el puerto TCP 8000. El protocolo SIP estará a la escucha en su puerto habitual, 5060 UDP.


\chapter{Conclusiones y proyectos futuros}
\section{Conclusiones}
A lo largo de la realización del proyecto se han presentado varias dificultades, que se detallan a continuacion:
\begin{enumerate}
	\item Problemas en la depuración de expresiones regulares: para corregir un fallo durante la entrada de datos, aunque esta ya se hubiera localizado en la expresión regular, su corrección resultaba bastante engorrosa. El proceso para comprobarla consistia en abrir un interprete Python aparte, importar los modulos correspondientes e imitar el mismo procedimiento que realiza el programa, lo que supone escribir 10 líneas de código que irremediablemente se perderán. Para evitar esto sería interesante escribir algúna clase de utilidad que facilite tanto la elaboración de patrones como su comprobación.
	\item Problemas con los clientes, ya que muchos de estos no se acomodan correctamente a las especificaciónes del protocolo, salvo en los casos en que se ha podido llegar a una solución elegante realizando pequeñas variaciones. En otros casos aceptar modificaciones sobre los protocolos normalmente ha implicado producir bastante código extra para subsanarlo.
	\item Las especificaciónes RFC son en muchos casos dificiles de entender. Para la implementación de los protoclos se ha hecho necesario obtener capturas de operaciones de dichos protocolos para comprender el procedimiento.
	\item Aún a pesar de utilizar un importante número de trazas a lo largo de la programación del servicio muchos errores solo pueden localizarse analizando el tráfico. Por ello disponer de programas como Wireshark \url{http://www.wireshark.org/} puede resultar de gran utilidad.
	\item Sería interesante adoptar una nomenclatura para los estados que derivan de otros estados sin alargar innecesariamente la longitud de las llamadas.
\end{enumerate}
Sin embargo en este proyecto si se han superado obstaculos en un tiempo menor de los esperado:
\begin{enumerate}
	\item El soporte para Datagram User Protocol se implementó en apenas 3 horas. Las diferencias con la versión que manejaba sockets TCP eran menores de lo esperado y la facilidad de implementación en Python redujo de manera importante el tiempo de implementación.
	\item Los módulos que incorpora Python para casi cualquier necesidad imaginable reduce el tiempo de implementación, sin embargo debe tenerse en cuenta que estos módulos deben estar presentes tambi\'en en los entornos donde vaya a ejecutarse el servicio.
	\item Las estructuras de datos primitivas de Python como listas y diccionarios han resultado muy utiles a la hora de almacenar la información de las cabeceras, al igual que las rutinas para tratamiento de cadenas.
\end{enumerate}

\section{Mejoras}

En futuras implementaciónes de BLAS se preveen una serie de mejoras planteadas para aumentar la funcionalidad de la plataforma o solventar sus carencias

\subsection{Cifrado}
Actualmente casi todos los servicios de red se comunican empleando canales seguros. Probablemente imitar cualquier servicio de forma completa requeriría aportar el soporte de distintos m\'etodos criptograficos. Algunos de los algoritmos mas comunes que se pueden localizar en internet son:
\begin{enumerate}
	\item{DES y 3DES: Publicados en 1976 y 1978 respectivamente. Son los algoritmos más veteranos y aun presentes en muchos sistemas aunque hayan perdido robusted con el paso del tiempo.}
	\item{IDEA: Publicado en 1991 para sustituir a DES}
	\item{Blowfish: Publicado en 1993}
	\item{RC5: Publicado por RSA en 1994}
\end{enumerate}
Para facilitar su uso por parte del programador y así mantener uno de los principales valores de la plataforma deben diseñarse m\'etodos para que una vez negociada una contraseña común el flujo de datos pueda mantenerse de forma identica al uso que se realizara sobre send() y receive(). Ya que Python permite la sobrecarga de m\'etodos desde la propia clase durante la ejecución implementar una rutina que reemplace los m\'etodos de entrada y salida no revestirá dificultad.

\subsection{Sistemas de registro opcionales}
Además del volcado de la información de registros de operación y errores al sistema de ficheros o a la salida estándar, existen otras posibilidades que pueden extender la funcionalidad de la plataforma:
\begin{figure}[h] %{h}{0.65\textwidth}
	%{figure}[h]
	\includegraphics[width=0.65\textwidth]{img/DiagramaClasesDisennoNewLogs.eps}	
              \caption{Diagrama de diseño. Nuevos registros}
  \label{fig:DiagramaClasesDisennoNewLog}
\end{figure}

\begin{enumerate}
	\item{Terminal TCP: Consistente en un servicio que tras conectarse mediante telnet permita revisar los eventos en el sistema.}
	\item{Volcado UDP: se enviarán a una ip y puerto predeterminados la información en texto claro de los eventos del sistema.}
\end{enumerate}

De esta manera se debería extender la clase Log, creando nuevas subclases que heredarian de Log, sobrecargando los m\'etodos para actuar de forma transparente al programador.


\subsection{Establecimiento como servicio del sistema}
Ya que Python es multiplataformai, según BLAS madure deberían acompañarsele procedimientos faciles para que los servicios producidos puedan implantarse en el sistema junto a otros.


Es importante implementar una rutina que permita un empaquetado facil del código y el software asociado (el imterprete Python con el juego de librerias necesario) para un despliegue del sistema lo mas agil y rápido posible.

\subsection{Construcción de expresiones regulares}
La construcción de expresiones regulares que acepten cadenas de acuerdo a un patron consumen tiempo y en ocasiones son el origen de fallos dificiles de diagnosticar. Por este motivo implementar un sistema para construir expresiones regulares de forma rapida y clara debería ser una de las prioridades a la hora de extender el proyecto.

El resultado ideal sería conseguir que no aparezcan expresiones regulares que entorpezcan la lectura del código de atención del servicio.
\section{Rendimiento y pruebas}
Para profundizar en las capacidades de la plataforma para implementar servicios en cierto nivel de producción, deberían realizarse una serie de estudios.
\subsection{Benchmarking}
Comparando con el rendimiento de otros servicios implementados sobre lenguajes más ligeros, como C, debería ofrecer una idea de que la necesidad de recursos que tiene la plataforma en función de la cantidad de clientes y el tipo de exigencia de estos. Conociendo estos requisitos podrán conocerse las posibilidades reales de que el prototipo pueda entrar en algún nivel de producción.

Sería interesante realizar distintos intentos según el nivel de optimización con que se configure la compilación a bytecode del producto.


\subsection{Seguridad}
Para obtener datos fiables sobre la confiabilidad del servicio producido, sobretodo si está expuesto a accesos de terceros, deben realizarse pruebas con intención de desestabilizar el programa o incluso acceder a recursos restringidos a traves de el.


\appendix
\include{fdl}
\include{gpl}
\begin{thebibliography}{99}
\bibitem{LibroCommandLine} Neal Stephenson: In the Beginning was the Command Line
	Editorial Harper Perennial, 1999.
\bibitem{Python} Python Software Foundation Web-Site: \url{http://www.Python.org}
\bibitem{RFCTCP} Especificación del Protocolo de Control de Transmisión (TCP): \url{http://www.rfc-es.org/rfc/rfc0793-es.txt}
\bibitem{RFCUDP} Especificación del Protocolo de Datagramas de Usuario (UDP): \url{http://www.rfc-es.org/rfc/rfc0768-es.txt}
\bibitem{RFCTELNET} Especificación del Protocolo Telnet: \url{http://www.rfc-es.org/rfc/rfc0854-es.txt}
\bibitem{RFCHTTP} Especificación del Protocolo de Transferencia de HiperTexto (HTTP): \url{http://www.ietf.org/rfc/rfc2616.txt}
\bibitem{RFCSIP} Especificación del Protocolo de Inicialización del Servicio (SIP): \url{http://www.rfc-editor.org/rfc/rfc3261.txt}
\end{thebibliography}
\end{document}


